Lowcode 随想

2019.12，自从公司的 Lowcode 项目立项已经接近半年了。从设计，到研讨，再到后期的开发，我们走过不少的弯路，这里记录一下完整跟完整个研发项目后产生的随想。

序幕

从项目立项之初，这几个问题就一直在困扰着我们

市面上的 Lowcode 项目已经很多了，为什么我们还要费时费力的开发这个项目？ 我们的项目，相比市面上的成熟 Lowcode 项目有什么竞争优势？

在最初一个月的调研过程中，我们调研了市面上很多的 Lowcode 产品，其中有相当一部分的功能都非常完善，且开发周期均在三年及以上。从产出比以及人员配比这个角度考虑，我们是很难在短期内赶超这些成熟的产品的，至于比肩 mendix、outersystem 这一类更加完善的产品更是痴人说梦了。

那么，我们产品的立足点究竟位于何处呢？

为了思考这个问题，我们回到了整个项目的基石，中台现目前使用的 DataSet 体系上，试图从这一套体系上寻求我们所希望的答案。

为什么会有 DataSet

举一个非常简单的例子，现目前你接到了一份总价 20w 的交付项目，要求在两个月内交付一套完备的中后台系统。其中绝大多数的页面，实际上都是 Table 和 Form 的简单堆叠。如果你希望在这个项目中获得更多的利润，你会从哪一方面入手？

1. 从销售入手，提升整个项目的总价
2. 从人天入手，维持整个项目总价不变的同时，削减项目本身占用最大的人天成本

1 这个选项，实际实施中很难被这种小微客户所接受，因此绝大多数情况下，我们只能从 2 入手解决问题。

这里就会带来另外一个问题，简单的削减人员，潜藏着交付质量降低的可能性。因此在削减人员的同时，我们需要提升单个人员的交付效率，从而保证整体的交付质量不变。

如何提升交付人员的交付效率呢？

后端的工作能在短时间内交给前端完成吗？貌似不行。

前端的工作能在短时间内交给后端做吗？页面复杂的情况下不太行，但是简单页面的情况下。。貌似还真的可以？

如何将前端的能力赋予后端？

这里我们总结一下需求：

1. 中后台应用中，最常见的应用场景就是 Form 和 Table
2. 后端最熟悉的是数据库表结构
3. 数据交互层面，最常见的也就是 CRUD 这一套逻辑

明确需求后，结合以往的 jsp 开发经验就可以抽象出一套专门针对后端开发使用的数据结构，这里我们将其称为 DataSet。

基于这一思路封装的 DataSet，对于纯粹的前端来说并不是十分友好，但是它有效解决了我司经常面对的这个问题：交付项目上的后端过多，如何将前端的能力有效赋予后端。

Lowcode 如何立足

回到那个核心问题，Lowcode 作为研发项目，必须具备为公司节约成本的特性。DataSet 迅速推广的核心特性在于：将前端的能力赋予后端，从而提升后端面对前端问题时的应对能力。

那么，如果我们转变一下思路，将 Lowcode 本身并不定义成一个产品，而是依托于公司中台产品的一项开发工具，其主要功能与特性类似于 DataSet，同样将前端开发的能力赋予其他人，但是覆盖面会更广，包括业务、销售、甚至可以是客户方的人员。

跳脱与同类产品做竞争的思路之后，我们的产品定位就非常明确了，Lowcode 本身就是一个非常单纯的，增强现有平台功能的工具。因此，我们并不需要一个 复刻版的Mendix、outerSystem，相反的，我们需要的是一个能够渐进式增强现有平台开发流程的工具。

从这个角度出发，我们自有的 Lowcode 就有了一条明确的开发路线。Lowcode 首次发版无法 cover 所有需求？没问题，客户方可以选择手工开发，同时我们的Lowcode 针对这一场景对产品进行优化，在下次发版的时候保证能够 cover 这一需求。

这样，我们的Lowcode就可以在发版初期，依托平台优势迅速推广，并快速收集大量的需求。根据业务需求本身进行高速迭代，经过短期的迭代后便可以覆盖简单的业务场景及需求。这样就同时解决了产品立足，以及后续迭代开发的相关方案。

由 Lowcode 开发所衍生出的随想

Lowcode 基于我司这一套 DataSet 体系而开发，可以理解为图形化的 DataSet 二次封装版本，项目本身的事件 / 模型等功能均强依赖于 DataSet 本身。在内部开发过程中，经常能见到技术吐槽这一套体系学习门槛高，约束过多，对新人不友好。

实际上在 DataSet 推广之初我就深刻体会过这一点，DataSet本身具有 80+ 的属性，且文档本身并没有完整的使用教程，DataSet 本身的文档都分散在各个组件内部，直接导致使用者获得的信息过于零散，代码绝大多数情况下都依靠口口相传。

要改善这一点，降低用户的学习成本，绝不是简单的两个教程就能解决的，更不是让现场的交付去看源码理解。必须要有一套对新人更加友好的工具。

经过漫长的思考，我想到了语法提示这个解决方案，如果我们把 DataSet 本身视作一门简易的语言，把常用的代码片段封装成简单的命令，通过命令便可以迅速生成一个 DataSet 初始化函数。

同理，文档中大量的属性，也可以放进 IDE 本身自带的语法提示中，配合视频教程 / 交互教程 ，就可以让交付在短时间内上手并使用这一整套体系。

实际上这个思路本身也并不新鲜，GraphQL 这种组件库也在 IDE 上存在大量的插件，如果我们希望让用户快速上手，完全可以借鉴这些成熟组件库的开发流程，提供插件来降低用户的开发成本。

而插件这个近乎 IDE 必备的功能也有非常丰富的想象空间，比如项目发版的时候需要执行很多的命令，我们就可以把这一流程抽象成一个插件，在 IDE 中进行图形化操作，点点按钮就可以完成项目的发布。抑或者和后端连调的时候，不断的切 Swagger 太过于麻烦，也可以将 Swagger 本身抽象成为插件嵌入 IDE，在不离开 IDE 的情况下完成日常开发所需的一切操作。这个思路本身，就是 Custom IDE，利用 IDE 的插件提升自身的开发效率。

后记

Lowcode 本身依然在高速迭代中，目前能够 cover 的业务场景依然有限，下一篇文章会从 Lowcode 重要的插件体系入手，讲一讲如何在开发项目中应用这套开发模式（提前立下 Flag）。